THESE 1

Bernhard Löwenstein: Die meisten Unternehmen machen nicht Scrum, sondern verwenden lediglich einen Scrum-ähnlichen Prozess. So werden beispielsweise immer wieder die Daily Stand-ups oder die Retrospektiven nicht gemacht. Dadurch geht aber manch großer Vorteil verloren, dessen sich die Unternehmen aber gar nicht bewusst sind.

Michael Schaffler: Geringfügige Anpassungen sollten erlaubt sein, um die speziellen Gegebenheiten innerhalb eines Unternehmens berücksichtigen zu können. Eine Methode zu dogmatisieren und sie stur in einer unreflektierten Weise zu befolgen, bringt größere Nachteile mit sich, als sich Freiraum für Adaptierungen zu lassen.

Das Wichtigste ist zu verstehen, was das Unternehmen an Funktionalität benötigt, und eine frühe Rückkopplungsschleife zu etablieren.

THESE 2

Bernhard Löwenstein: Bei den früher klassischen Vorgehensmodellen gab es immer einen großen Aufschrei der Entwickler, wenn Codeteile im Nachhinein geändert werden mussten. Bei Scrum sind in den meisten Projekten die zwischendurch durchgeführten Codeadaptierungen noch wesentlich umfangreicher, allerdings wird dies nicht bewusst wahrgenommen. Um es mit einer Metapher auszudrücken: Am Ende steht zwar ein fertiges Haus, aber auf dem Weg dahin hat man oft in Summe auch ein ganzes Haus wieder eingerissen.

Michael Schaffler: Die Frage ist letztendlich, ob Kent Beck Recht behält, dass ständiges Refactoring des Codes in Summe weniger aufwendig ist, als eine vollständige Spezifikation und Architektur zu entwerfen und diese in einem umzusetzen. Welcher Ansatz der ökonomischere ist – und das sollte die Maxime sein – hängt wahrscheinlich auch von den Geschäftsmodellen der Unternehmen ab. Eines ist klar, die Unternehmen müssen heute wesentlich schneller auf Veränderungen im Markt reagieren, als dies vor zwanzig Jahren der Fall war. Diese Steigerung der Agilität der Geschäftsmodelle muss auch seinen Niederschlag in der Softwareentwicklung finden.

Der Agile & Culture Track auf der JAX 2018

THESE 3

Bernhard Löwenstein: Es wird bei Scrum vorab kaum mehr etwas spezifiziert, sondern die Produktivität wird vorrangig daran gemessen, wie schnell die Entwickler loslegen und etwas Herzeigbares liefern. Das endet oftmals in Code, der deutlich eleganter geschrieben hätte werden können, oder in Architekturen, die sich später als suboptimal herausstellen.

Michael Schaffler: Das Wichtigste ist zu verstehen, was das Unternehmen an Funktionalität benötigt, und eine frühe Rückkopplungsschleife zu etablieren. Wenn Analyse und Umsetzung von einem Team bewerkstelligt wird und dieses noch dazu eng mit den Fachbereichen zusammenarbeitet, so kann die Dokumentation auf ein Minimum reduziert werden. Kommt es hier zu einem Bruch (strikte Trennung von Anforderungsanalyse und Umsetzung), so wird geschriebene Dokumentation in höherem Maße notwendig, sonst geht Wissen verloren. Scrum propagiert Ersteres und kann damit zu Recht auf eine hohe Dokumentationslast verzichten.

Unternehmen müssen heute wesentlich schneller auf Veränderungen im Markt reagieren, als dies vor zwanzig Jahren der Fall war.

 

THESE 4

Bernhard Löwenstein: Entwickler lieben Scrum vor allem deshalb, da die lästige Arbeit des Dokumentierens auf ein Minimum reduziert wird und das Programmieren im Vordergrund steht. Das erzeugt den Eindruck, dass man stets produktiv ist, auch wenn dies gesamtheitlich betrachtet nicht so der Fall ist.

Michael Schaffler: Dem würde ich widersprechen. Entwickler mögen Scrum, weil sie Planung und Aufgabenteilung eigenverantwortlich mitbestimmen, anstatt Aufwände und Arbeitspakete von einem Projektleiter aufs Auge gedrückt zu bekommen. Eigenverantwortung stärkt die Motivation, und Motivation ist der Schlüssel jedes Erfolgs.

THESE 5

Bernhard Löwenstein: Wer Scrum mit den früher klassischen Vorgehensmodellen vergleicht, macht oft den Fehler, dass er Scrum inklusive der heute bereitstehenden Werkzeuge und Techniken mit dem früher klassischen Prozess exklusive dieser Werkzeuge und Techniken vergleicht (da es diese eben damals noch nicht gab). Klarerweise scheint Scrum dann den „alten“ Vorgehensmodellen deutlich überlegen zu sein.

Michael Schaffler: Die Tools spielen in Scrum eine untergeordnete Rolle. Scrum hat hier gegenüber althergebrachter Methoden keine Vorteile. Die große Schwäche von Scrum ist aus meiner Sicht, dass keine Antwort auf die Frage gegeben wird, wie mittelfristige Planung anzugehen ist und wie Festpreisprojekte abgewickelt werden sollten. Hier gäbe es Potenzial zur Weiterentwicklung. Stattdessen ist aber eine Mystifizierung und sektenartige Einschwörung auf den Prozess zu beobachten.